[レポート] マルチアカウント運用での権限移譲と統制の両立 #AWSSummit

AWS Summit Tokyo 2019

#AWS

#イベントレポート

森田桂介

2019.06.14

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS Summit Tokyo 2019 Day2 で開催された「マルチアカウント運用での権限移譲と統制の両立」についてレポートします。

セッション情報

スピーカー：山辺真行氏（アマゾンウェブサービスジャパン株式会社）

セッション名：マルチアカウント運用での権限移譲と統制の両立

社内やチームでのAWS利用が浸透するにつれてニーズや利用形態は多様化していきます。このような状況でAWS環境の管理者ユーザーの皆様はなるべく利用者に権限を移譲し自由に利用させたいと考える反面、全社的なセキュリティやコスト管理の統制に悩まれているかと思います。本セッションでは、マルチアカウント運用で利用者に権限を移譲しつつ全体的な統制も効かせる方法について解説します。

自己紹介

プロフェッショナルサービスにおいて、エンタープライズのお客様の主に運用

セッション内容

組織内でAWS利用が拡大する中で遭遇する権限移譲と統制についてどのように対処するか、具体的な例を上げて解説
権限移譲と統制においては複数のAWSアカウントをどのように運用するかが鍵
複数のAWSアカウントを運用するために効果的なAWSのサービスの各機能については概要の説明に留める

アジェンダ

AWSアカウントとマルチアカウント環境
権限移譲の例
セキュリティと統制
まとめ

AWSアカウントとマルチアカウント環境

AWSアカウントとは
- セキュリティ上の境界
  - S3のデータなどは明示的に開放しない限り他のアカウントからは参照できない
- リソースや制限の管理単位
  - アカウントごとにソフトリミットが存在する
  - EC2の起動数など
- コスト管理の分離単位
AWSアカウントは増える傾向にある
- 少数のアカウントから利用開始する
- AWSになれてくると多数のアカウントに増えていく
AWSアカウントが増える理由
- 多くのチームが使い出す
  - 共同で1つのアカウントを使用すると制限にかかる場合がある
- セキュリティと統制
  - 重要な情報を扱っているシステムは別で管理したい
- コスト管理
  - プロジェクトや部署で予算が別れている場合
  - 1つのアカウントで管理することはできるが面倒
- 環境の分離
  - 開発、ステージング、本番などで分ける
- プロセス
マルチアカウント環境で考えるべきこと
- 責任分担と権限移譲
  - 複数の組織でどういう責任があり、どういう操作が可能なのか把握する
  - 各チームの責任分担を明確化する
  - AWSサービスの利用者（開発者）にAWSの操作権限を移譲する
  - AWS環境の統制、監視のための組織を作る
- セキュリティと統制
  - 認証、認可を正しくつかっているか監査する
  - AWSアカウントを跨ぐアクセス管理
  - 環境全体のAWS操作権限
    - やってはいけないことをブロックする、検知する
  - ネットワークの中央管理
    - マルチアカウント環境ではVPCが複数存在する。場合によっては他のアカウントと接続する必要がある。自由にすると複雑なネットワークが出来上がる。
- 運用
  - 効率的に運用されているのか
  - 正しく運用されているのか
  - 共通設定の確実な展開、自動化
  - 全体環境を俯瞰した監視、ログ収集
  - 利用者自身によるコスト管理
利用者への権限移譲が必要な理由
- これまでは基盤チームがセットアップしてアプリ開発者に対して環境を提供していた
- 中央集権の限界、開発者はAPI GatewayやLambdaを使いたくなってくる。基盤チームだけでは対応できなくなってくる
- 権限移譲
  - 開発者に対して権限を移譲する

権限移譲の例

多様な組織のパターンが有る
よくある例
- 管理者（基盤チーム）
  - AWSアカウントの作成、管理
  - AWSアカウントのアクセス管理
  - 共通設定の展開
- セキュリティ担当者
  - セキュリティイベントの通知先
  - AWSログの監査
- 利用者（開発者）
  - AWSリソースの作成
  - 各利用者自身のコスト管理

セキュリティと統制

管理者のタスク
- AWSアカウントを跨ぐアクセス管理
  - IAMはアカウントに閉じたもの
  - アカウントそれぞれにIAMユーザが必要
  - 横断的にアクセスしたい、管理したい
    - SSOで実現できる
      - SSO自体にユーザディレクトリを保持できる
      - 本セッションではAWSアカウントへのアクセスをActive Directoryで認証を解説
      - 権限（認可）の一元管理
      - 東京リージョン未サポート（2019年6月13日時点）
- AWSアカウントの作成、管理
- AWSアカウントのアクセス管理
- 共通設定の展開
AWS SSOとActive Directoryとの接続
- AWS上またはオンプレミスのADと接続可能
- 東京リージョンのADを利用する例
  - 東京にAWS Managed Microsoft ADを作成
  - バージニア北部にActive Directory Connectorを作成しAWS SSOを参照
  - 東京とバージニア北部はInter Retion VPC Peeringで接続
- オンプレミスのADを利用する例
  - オンプレミスにActive Directoryがある
  - 東京にAWS Managed Microsoft ADを作成しオンプレミスと連携
  - バージニア北部にActive Directory Connectorを作成しAWS SSOを参照
  - 東京とバージニア北部はInter Retion VPC Peeringで接続
  - オンプレミスと東京リージョンはDXまたはVPNで接続
ADグループとAWSアカウントとのマッピング
- 複数アカウントある場合に関連付けをどうするか
  - Permission Setsが使える
AWSアカウント単位での権限制御
- AWS Organizations
  - AWSアカウントのルートユーザの権限もコントロールできるService Contorol Policy（SCP）を活用
  - マスターアカウントから子アカウントに’対してCloudTrailの利用を強制したりできる

運用

共通設定の展開
全アカウントに共通の設定例
- AWS CloudTrailの有効化（AWS API操作証跡）
- AWS Configの有効化（AWS構成と変更履歴）
- AWS Config Rulesの展開（MFAなどの準拠チェック）
CloudFormation Stack Sets
- 1つのテンプレートを複数のAWSアカウント及び複数のリージョンに展開可能
- 必ず設定しておきたいものを展開できる
セキュリティチームのタスク
- 監視・収集する対象
- Amazon GuardDuty
  - 脅威を検出
  - アカウントが悪用されている、ポートスキャンされているなどを検知
- 複数アカウントのログ、イベントを集約監視
  - セキュリティアカウントを作成し、GuardDutyの脅威検知、セキュリティに関する通知を集約
  - ログアカウントを作成し、AWS CloudTrail、AWS Configのログを集約する
  - これで環境全体にスキャンができる
これだけの仕組みを作るのは大変
- AWS Landing Zone でセキュリティと統制環境の自動構築
  - ベストプラクティスに基づいて、セキュアなマルチアカウントのAWS環境をより迅速に設定するセルフホスティングのツール
  - 概要
    - マスターアカウント、ログ管理用アカウント、監査用アカウント、共有サービスアカウントをAWS Orgaizationsで作成、管理
    - AWS SSOによるシングルサインオン事前構成（AD連携可）
    - AWS Config、AWS CloudTrail、Amazon CloudWatchによる統合監視とアラート